Modern DevOps: Connecting business and IT

Bringing teams from different fields together in a good way is rarely easy, when those teams are involved in the same business processes but do not work together directly. That’s why a group of people led by Patrick Debois suggested a new concept back in 2009: DevOps. They offered a solution to tackle the problem which exists in both development (Devs) and administrative (Ops) level. The DevOps movement developed substantially and made fundamental changes to basic concepts in IT and their roles in organizations.

Business-driven DevOps

Originating from the idea of making processes in conventional IT settings – classic on-premise-server, separated dev- and ops-departments – smoother, the DevOps movement is now mostly concerned with consistent digitalisation and areas with a high pressure to innovate.

Powered by the internet, many industries are subjected to an increasing pressure to change. While some are still looking back half-heartedly at their losses in traditional market shares, others are already making steps toward an open, hard-to-plan future. Consistent digitalisation and high-performance IT-structures are imperative – as demonstrated by renowned companies such as Netflix, Spotify, and Uber.

What exactly are the driving forces in business towards a DevOps culture? Allow me to start by naming some (although certainly not all) buzzwords:

• Globalization results in increased competition in almost all industries.
• The internet is more than just a modern marketing and sales platform for traditional fields of business. It has the power to transform classic business models, modify them or make them obsolete altogether.
• Disruption is not an exception, but will be the norm in most markets. The ability to innovate will, therefore become the key to success for companies.
• Therefore, markets cannot be perceived as stable, making long-term planning obsolete. Iterative strategies and many changes will become essential for companies’ success.

Five factors of DevOps

Modern DevOps does more than just bring together Devs and Ops; it aims to integrate business and IT across teams and systems. We would like to discuss the relationship between business and IT with speakers from around the world at our DevOpsCon conference which takes place between 5-8 December.

I will now try to outline the most important movements which can bring a sustainable change towards DevOps if brought together. I would also like to talk about what inspired us —myself and Peter Rossbach—to design the program of our DevOps conference.

If we want to make extensive changes, the gradual improvement of conventional systems is not enough. We need to focus on the following aspects:

1. Continous Delivery
2. Microservices
3. Cloud Platforms
4. Container Technology
5. Business Culture

Let’s take a closer look at each of these five factors and how they come together.

Continuous Delivery

Continuous Delivery – automating each and every aspect of delivery – has been an important aspect for online companies for quite a while. Bringing bugfixes, modifications and new features into production as fast as possible without taking too big a risk represents a very important goal.

Such companies usually don’t bring new software releases into production every six months; they don’t just do that every month or even every day but in most cases several times a day! Why is it that many small releases are better suited for such teams than just a few big ones? Because this prevents large backlogs from building up in the first place. Pending work? Doesn’t fit into the mindset of continuous delivery proponents. Important changes to usability or improvements to performance don’t have to wait until the next big release, they are put into production immediately. Even if that code does not stay the same too long, these modifications can also be rolled out without delay.

This culture of welcoming well thought-through experiments, encouraging all contributors (not just application developers) to try something new because they know a path once taken can always be corrected if new insights suggest so is part of the world we live in right now.

Continuous Delivery is putting gentle pressure on developers to optimize their software for smooth deployment. Developers will put more thought into architectural concerns and technical details that are important for deployment when they are responsible for transferring applications to real life, rather than just take responsibility for applications in test environments.

Microservices

Microservices are modeled with one goal in mind: to reduce complexity in software systems. The theory reads as follows: By “cutting” software into small “bites”, inherent complexity can be reduced. This revelation is added to the long history of ideas on modularity of software in IT (from object-oriented programming and component orientation to SOA and even modularizations like OSGi and Jigsaw.)

Dependencies between parts of the system, being responsible for problems around complexity, are eliminated this way; when working with microservices, they can be resolved by using APIs: When you change a service, you are obligated to consider “neighbouring services” to ensure the API stays consistent. You need to keep this important goal in mind throughout all development and deployment activities. If you have to change an interface, it’s easier to explicitly tell all neighbouring services and initiate a cooperative plan to kick off the change.

There is no need to use the same technologies for all microservices (one can be written in Java, another in Ruby on Rails, the next one in Go in the cloud …). Many experts see this as an advantage. We are merely mentioning this aspect as a side note; its relevance to the DevOps perspective is not a major one.

It is important to mention that microservices should not be seen simply as a new style of architecture which can replace other architectures and lead to better technical results. Microservices represent a new solution not only for technology but also for the organisation.

It makes sense to use microservices when you wish to change certain things beyond technology. These encompass:

1. Autonomous, self-organising teams, each taking full responsibility for one (micro-) service.
2. Technical considerations are not the driving force behind the design of such services; functional considerations are (explaining the vast popularity of domain-driven design in the field of microservices).
3. “You build it, you run it”, this quote by Werner Vogels (CEO at Amazon Web Services) is a description of the responsibilities of microservice teams. They are not just responsible for developing an application, but also for its full lifecycle, meaning deployment, monitoring, bug fixing, optimizations, further development …
4. Furthermore, microservice teams are often cross-functional – that is to say, there might be operations/platform experts in the team, in addition to application developers; quite often domain experts, marketing specialists and designers join the team too.

Microservices are beneficial in the long run only to such organizations which are seeing them not just as some technical innovation, but as a way to follow their business goals.

Cloud

Modern cloud platforms represent more than an opportunity to transfer applications to public data centres. In fact, they are offering plenty of technical services which are challenging the conventional ways of building and using software.

Where can the consequences of this cloud paradigm be seen in reality? You need to put some serious effort into deploying an application in classic environments: You must choose an operating system and set it up, add application servers, database, manage users and permissions, configure a firewall, manage compatibilities and dependencies. Having done all this, the application itself finally needs to be configured and adjusted to any given production environment.

Modern cloud environments such as Amazon Web Services, Microsoft Azure or Google Cloud Platform make this process substantially easier. Complicated infrastructures from the traditional on-premise-world are almost trivial in comparison! Data management, user and permissions management (identity), networks, management and monitoring, scaling are at hand as services in such environments. Calling one of those services takes just seconds to complete.

Container

Container technologies, made popular by Docker, solve a long-standing problem of the software world in an elegant way: How can you make software running in one system context run easily in another system context?

Containers separate software from factors like operating system versions, library-conflicts or network topologies, making the “transfer” of an app from the test environment into production system less “painful” than before.

What is the difference between Docker or CoreOS (to also mention the alternative container platform besides Docker) and traditional virtualization? Classic virtualization systems bundle not just the application, but also the corresponding operation system and further components into a package. Therefore, a machine needs to run three operating systems in addition to its primary OS when running three virtualization instances.

Docker and CoreOS virtualize only the application plus selected libraries while using shared access to services from the system kernel. This leads to decreased start-up times in comparison to classic VMware instances. With those, start-up takes up to minutes; with Docker, it takes seconds. Because of these properties, Docker virtually invites developers to split complex applications into small bites in microservices style.

Business culture

None of the above will start a revolution in IT on its own. Taken together they are able to change the tune unequivocally.

Continuous Delivery opens up new mental spaces in companies to shape their digital business. In the light of high releases frequencies, IT can be seen as an agile and ductile medium instead of a rigid shell that needs huge investments to initiate change.

Microservices facilitate such automated deployments by substantially reducing volume and complexity of the artefacts to deploy. They help companies focus on business goals, meaning that they do not let software infrastructures defined in the past decide the layout and focus of departments; instead, they help companies focus on goals and services that make sense business wise.

Furthermore, crossfunctional microservice teams promise to nullify classic boundaries between specialty departments / marketing / design / development / operations and, therefore, encourage different stakeholders to collaborate in a lively, multidisciplinary way focussed on the success of the product. When teams, put together like this, cultivate a communication culture in the spirit of Agile, without constraints from hierarchic structures, iterative development of products guided by (changing) customer needs is being facilitated. An agile infrastructure as defined by DevOps can supply a likewise iterative IT.

Cloud platforms help such iterative businesses on a technical level as solely software-based infrastructures; Docker containers are helpful too. Those make deployment and changes to the infrastructure a no-brainer and could potentially dispose of the image of IT being the “party pooper” in business development once and for all.

Final thoughts

In our understanding, modern DevOps will work only when combined with the techniques presented in this article. The topics – Continuous Delivery, Microservices, Clouds, Docker, Business Culture – might be subject to controversial discussions; certainly there are many important topics to be mentioned.

Furthermore, not all of the ingredients mentioned above are needed to build a “real” DevOps. In fact, I’ve heard of true Continuous Delivery miracles that are based on one single mega-monolith (instead of microservices) and of intelligent applications of microservices completely without clouds and container.

There is no “true DevOps”, just as there is no one authoritative definition of DevOps. Defining DevOps as being the description of a movement that forces us to rethink our basic understanding of IT, should do for now (and, of course, will be discussed at our DevOpsCon, that did not gain the motto of “Rethink IT” by chance).

I’m looking forward to many sessions, keynotes, and workshops, as well as lots of enthralling impulses and enlightening conversations. All of our speakers are well-versed in DevOps environments, some as infrastructure experts, some as application developers in the cloud, others as transformation consultants for companies.

Will I see you at DevOpsCon?